Draft

OGC Engineering Report

•
2022 Web Mapping Code Sprint Summary Engineering Report
Gobe Hobona Editor Joana Simoes Editor
Submission Date: 2018-12-20 Approval Date: 2018-07-10 Publication Date: 2028-06-12 External identifier of this OGC® document: http://www.opengis.net/doc/PER/eoep-Hack2018 Internal identifier of this OGC® document: 22-054
OGC Engineering Report

Draft

Notice

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard.

Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

Document number:22-054
Document type:OGC Engineering Report
Document subtype:
Document stage:Draft
Document language:English

Copyright notice

Copyright © 2022 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.ogc.org/legal/

Note

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.


License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.


I.  Executive Summary

The code sprint focused on the following group of specifications:

The sprint objectives for the Standards Working Groups (SWGs) were to:

This engineering report makes the following recommendations for future innovation work items:

The engineering report also makes the following recommendations for things that the Standards Working Groups should consider:

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

hackathon, application-to-the-cloud, testbed, docker, web service

III.  Security considerations

No security considerations have been made for this document.

IV.  Submitters

All questions regarding this document should be directed to the editor or the contributors:

Name Organization Role
Gobe Hobona Open Geospatial Consortium Editor
Joana Simoes Open Geospatial Consortium Editor
Andreas Matheus Secure Dimensions Contributor
Antonio Cerciello OSGeo Contributor
Clemens Portele interactive instruments GmbH Contributor
Erwan Bocher CNRS (National Center for Scientific Research) Contributor
Francesco Bartoli OSGeo Contributor
Iván Sánchez Ortega OSGeo Contributor
Jérôme Jacovella-St-Louis Ecere Corporation Contributor
Joan Maso UAB-CREAF Contributor
Keith Pomakis MariaDB Contributor
Núria Julià Selvas UAB-CREAF Contributor
Olivier Ertz HEIG-VD (School of Management and Engineering Vaud) Contributor
Prajwalita Chavan IIT Bombay Contributor
Tim Schaub Planet Labs PBC Contributor
Tom Kralidis Meteorological Service of Canada Contributor
Add Name Add Name Contributor
Add Name Add Name Contributor
Add Name Add Name Contributor

V.  Abstract

The subject of this Engineering Report (ER) is a code sprint that was held from November 29th to December 1st, 2022 to advance OGC API Standards that relate to web mapping, and others that relate to styling and symbology encoding standards. The code sprint was hosted by the Open Geospatial Consortium (OGC) and EuroGeographics. The code sprint was sponsored by Ordnance Survey (OS), and was held as a hybrid event with the face-to-face element hosted at the Mundo Madou centre in Brussels, Belgium.

2022 Web Mapping Code Sprint Summary Engineering Report

1.  Scope

A Code Sprint is a collaborative and inclusive event driven by innovative and rapid programming with minimal process and organization constraints to support the development of new applications and open standards. Code Sprints experiment with emerging ideas in the context of geospatial standards, help improve interoperability of existing standards by experimenting with new extensions or profiles, and are used for building proofs of concept to support standards development activities and enhancement of software products.

The code sprint described in this engineering report focused on the following specifications:

The code sprint was organized to provide a collaborative environment that enables software developers, users, and architects to work together on open standards that relate to web mapping, styles, and symbology. The engineering report presents the sprint architecture, the results of the prototyping, and a discussion resulting from the prototyping.

2.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Joan Masó , Jérôme Jacovella-St-Louis: OGC 17-083r4, OGC Two Dimensional Tile Matrix Set and Tile Set Metadata. Open Geospatial Consortium (2022). https://docs.ogc.org/is/17-083r4/17-083r4.html.

Joan Masó, Jérôme Jacovella-St-Louis: OGC 20-057, OGC API — Tiles — Part 1: Core. Open Geospatial Consortium (2022). https://docs.ogc.org/is/20-057/20-057.html.

Charles Heazel: OGC API — Common — Part 1: Core (Draft). OGC 19-072, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/19-072.html

Charles Heazel: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-024.html

Leonard Daly, Rollin Phillips: OGC 20-058, Interoperable Simulation and Gaming Sprint Year 2 Engineering Report. Open Geospatial Consortium (2021). https://docs.ogc.org/per/20-058.html.

Clemens Portele: OGC API — Styles (Draft). OGC 20-009, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-009.html

Markus Lupp: OGC 05-078r4, OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification. Open Geospatial Consortium (2007). https://portal.ogc.org/files/?artifact id=22364.

WHATWG. HTML, Living Standard [online, viewed 2022-12-08]. Available at https://html.spec.whatwg.org/

3.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

3.1. API

An Application Programming Interface (API) is a standard set of documented and supported functions and procedures that expose the capabilities or data of an operating system, application, or service to other applications [adapted from ISO/IEC TR 13066-2:2016].

3.2. coordinate reference system

A coordinate system that is related to the real world by a datum term name [source: ISO 19111]

3.3. dataset

a set of data, published or curated by a single agent, and available for access or download in one or more representations (modified from DCAT: https://www.w3.org/TR/vocab-dcat-2/#dcat-scope).

Note 1 to entry: A Web API implementing OGC API — Common often gives access to a single dataset which may be comprised of one or more geospatial data resources.

3.4. geospatial data resource

web accessible resource that consists of a set of geospatial data

Note 1 to entry: In Web APIs implementing OGC API — Common — Part 2: Geospatial Data, geospatial data resources are referred to as collections and are defined in the collections conformance class.

Note 2 to entry: geodata is sometimes used in this document as an abbreviation of geospatial data

3.5. geospatial resource aspect

web accessible resource that represents a component of geospatial information (metadata, schemas…​) or geospatial data accessed using a particular mechanism and data model (e.g., feature items, tiles, maps, coverages,…​) of a more generic geospatial data resource (e.g., a collection)

Note 1 to entry: Not to be confused with a web accessible resource representation. While resource representations share the same path and are selected by format negotiation, geospatial aspects use different paths. Commonly a geospatial aspect is a subpath of a geospatial data resource.

3.6. map tile

tile that contains information in a raster form where the values of cells are colors which can be readily displayed on rendering devices

Note 1 to entry: Map tiles are generated in combination with OGC API — Maps.

3.7. OpenAPI Document

A document (or set of documents) that defines or describes an API. An OpenAPI definition uses and conforms to the OpenAPI Specification (https://www.openapis.org)

3.8. geographic information

information concerning phenomena implicitly or explicitly associated with a location relative to the Earth (source: ISO 19101)

3.9. map

portrayal of geographic information as a digital image file suitable for display on a computer screen (source: OGC 06-042)

3.10. portrayal

presentation of information to humans (source: ISO 19117)

3.11. map tile

tile that contains information in a raster form where the values of cells are colors which can be readily displayed on rendering devices

Note 1 to entry: Map tiles are generated in combination with OGC API — Maps.

3.12. tile

geometric shape with known properties that may or may not be the result of a tiling (tessellation) process. A tile consists of a single connected “piece” without “holes” or “lines” (topological disc).

In the context of a 2D tile matrix, a tile is one of the rectangular regions of space, which can be uniquely identified by row and column integer indices, making up the tile matrix.

In the context of a geospatial data tile set, a tile contains data for such a partition of space as part of an overall set of tiles for that tiled geospatial data.

Note 1 to entry: From OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space

Note 2 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

Note 3 to entry: Tiles are useful to efficiently request, transfer, cache, display, store and process geospatial data for a specific resolution and area of interest, providing deterministic performance and scalability for arbitrarily large datasets.

Note 4 to entry: Tiles can contain a variety of data types, such as grid-based pictorial representations (map tiles), coverage subsets (coverage tiles), or feature-based representations (vector tiles).

3.13. tile matrix

tiling grid in a given 2D coordinate reference system, associated to a specific scale and partitioning space into regular conterminous tiles, each of which being assigned a unique identifier

Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

Note 2 to entry: Each tile of a tile matrix is uniquely identifiable by a row and a column integer index. The number of rows is referred to as the matrix height, while the maximum number of columns is referred to as the matrix width (the number of columns can vary for different rows in variable width tile matrices).

3.14. tile matrix set

tiling scheme consisting of a set of tile matrices defined at different scales covering approximately the same area and having a common coordinate reference system.

Note 1 to entry: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard

3.15. tile set

a set of tiles resulting from tiling data according to a particular tiling scheme

Note 1 to entry: From OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space, but adapted to clarify that in the context of this document, a tile set refers specifically to a set of tiles containing data and following a common tiling scheme.

3.16. Web API

API using an architectural style that is founded on the technologies of the Web [source: OGC API — Features — Part 1: Core]

3.17.  Abbreviated terms

API

Application Programming Interface

CRS

Coordinate Reference System

GIS

Geographic Information System

OGC

Open Geospatial Consortium

OWS

OGC Web Services

REST

Representational State Transfer

4.  High-Level Architecture

As illustrated in Figure 1, the sprint architecture was designed with the view of enabling client applications to connect to different servers that implement open geospatial standards that relate to web mapping, styles and symbology. Implementations of OGC API — Maps, OGC API — Tiles, and OGC API — Styles were deployed in participants’ own infrastructure in order to build a solution with the architecture shown below in Figure 1.

Figure 1 — High Level Overview of the Sprint Architecture

The rest of this section describes the software deployed and standards implemented during the code sprint.

4.1.  Approved and Draft Standards

This section describes the approved and draft standards implemented during the code sprint.

4.1.1.  OGC API — Maps

The OGC API — Maps draft specification describes an API that can serve spatially referenced and dynamically rendered electronic maps. The specification describes the discovery and query operations of an API that provides access to electronic maps in a manner independent of the underlying data store. The query operations allow dynamically rendered maps to be retrieved from the underlying data store based upon simple selection criteria, defined by the client.

4.1.2.  OGC API — Styles

OGC API — Styles specifies building blocks for Web APIs that enable map servers and clients as well as visual style editors to manage and fetch styles that consist of symbolizing instructions that can be applied by a rendering engine on features and/or coverages. The API implements the conceptual model for style encodings and style metadata. The model defines three main concepts, namely the style, stylesheet, and style metadata. The concepts are explained below:

  • The style is the main resource.

  • Each style is available in one or more stylesheets — the representation of a style in an encoding like OGC SLD 1.0 or Mapbox Style. Clients will use the stylesheet of a style that fits best based on the capabilities of available tools and their preferences.

  • For each style there is style metadata available, with general descriptive information about the style, structural information (e.g., layers and attributes), and so forth to allow users to discover and select existing styles for their data.

4.1.3.  OGC API — Tiles

OGC API — Tiles specifies a standard for Web APIs that provide tiles of geospatial information. The standard supports different forms of geospatial information, such as tiles of vector features (“vector tiles”), coverages, maps (or imagery) and potentially eventually additional types of tiles of geospatial information.

Vector data represents geospatial objects such as points, lines, and polygons. Tiles of vector feature data (i.e. Vector Tiles) represent partitions of vector data covering a large area (e.g. lines representing rivers in a country).

In this context, a map is essentially an image representing at least one type of geospatial information. Tiles of maps (i.e. Map Tiles) represent subsets of maps covering a large area (e.g. a satellite image).

4.1.4.  OGC STAplus — an extension of the OGC SensorThings API

STAplus is an extension to the OGC SensorThings data model. Inspired by Citizen Science applications, STAplus supports the ‘ownership concept’ whereby observations collected by sensors are owned by (different) users that may express the license for re-use. In addition to the ownership and license abilities, the extension specified by STAplus supports the expression of explicit relations between observations and the creation of group(s) of observations.

4.1.5.  OGC Styled Layer Descriptor

The Styled Layer Descriptor (SLD) encoding standard defines an encoding that supports user-defined symbolization and coloring of geographic feature and coverage data. SLD addresses the need for users and software to be able to control the visual portrayal of the geospatial data. The ability to define styling rules requires a styling language that the client and server can both understand. SLD is often used in combination with the OGC Symbology Encoding Standard (SE).

4.1.6.  OGC Styles and Symbology

The OGC Symbology Conceptual Model: Core Part standard (OGC 18-067r3), also known as OGC SymCore, specifies the conceptual basis to define symbology rules for the portrayal of geographical data. It is modular and extensible (one core model, many extensions), also encoding agnostic (one symbology model, many encodings). It contains a minimal set of abstract classes representing explicit extension points of the model.

OGC Styles and Symbology is a vision for a standard that implements the OGC Symbology Conceptual Model: Core Part standard (OGC 18-067r3). The Web Mapping Code Sprint was a key moment to consolidate the roadmap to achieve this vision. The plan towards such a candidate SymCore 2.0 standard specdoc will consist in the definition of a conceptual and logical model, CSS and JSON encodings and a mapping to SLD/SE (eventually with existing well known vendor options). The requirements described will be supported by illustrated and encoded cartographic use cases.

4.2.  Open Source Software Projects

This section describes open source software products that were deployed during the code sprint.

4.2.1.  Leaflet

Leaflet is a popular Javascript library for displaying maps in web pages, created in 2011 by Volodymir Agafonkin and released under a BSD-2 license. It has a minimalistic architectural design in order to provide a small code footprint. As a result, any advanced or specific functionality is implemented by plugins.

Leaflet.ImageOverlay.OGCAPI is a Leaflet plugin implementing a OGC API — Maps client, and was created during a previous codesprint.

4.2.2.  ldproxy

ldproxy is an implementation of the OGC API family of specifications, inspired by the W3C/OGC Spatial Data on the Web Best Practices. ldproxy is developed by interactive instruments GmbH, written in Java (Source Code), and is typically deployed using docker (DockerHub). In addition to supporting commonly used data formats for geospatial data, an emphasis is placed on an intuitive HTML representation.

The current version supports PostgreSQL/PostGIS databases, GeoPackages and WFS 2.0 instances as backends for feature data. MBTiles is supported for tilesets.

ldproxy implements all conformance classes and recommendations of “OGC API — Features — Part 1: Core” and “OGC API — Features — Part 2: Coordinate Reference Systems By Reference” and is an OGC Reference Implementation for the two standards. ldproxy also supports the OGC API Records draft as well as the draft extensions of OGC API — Features (that is Part 3, CQL2, Part 4 and most of the current proposals discussed by the Features API working group). It supports GeoJSON, JSON-FG, HTML, FlatGeoBuf, CityJSON, glTF 2.0 and GML as feature encodings.

ldproxy also has implementations for additional resource types: Vector and Map Tiles, Styles, Routes, 3D Tilesets.

ldproxy is distributed under the Mozilla Public License 2.0.

4.2.3.  OSGeo OWSLib

OWSLib is a Python client for OGC Web Services and their related content models. The project is an OSGeo Community project and is released under a BSD 3-Clause License.

OWSLib supports numerous OGC standards, including increasing support for the OGC API suite of standards. The official documentation provides an overview of all supported standards.

4.2.4.  OSGeo pygeoapi

pygeoapi is a Python server implementation of the OGC API suite of standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license. pygeoapi is an official OSGeo Project as well as an OGC Reference Implementation.

pygeoapi supports numerous OGC API Standards. The official documentation provides an overview of all supported standards.

4.2.5.  STAplus Viewer App by Secure Dimensions

The STAplus Viewer App is a proof of concept implementation as Web-Browser application based on JavaScript and Leaflet. The implementation further leverages JS libraries from STAM (SensorThings API Map) developed by Datacove for INSPIRE.

The STAplus Viewer App is based on the Leaflet JavaScript library. It is however possible to base the application on OpenLayers. This alternative implementation is available from the COS4Cloud project. Even though it looks and feels slightly different, both implementations provide the same functionality.

4.2.6.  TEAM Engine

The Test, Evaluation, And Measurement (TEAM) Engine is a testing facility that executes test suites developed using the TestNG framework or the OGC Compliance Test Language (CTL). It is typically used to verify specification compliance and is the official test harness of the OGC Compliance Testing Program (CITE).

4.2.7.  OpenLayers

OpenLayers is a library for developing browser-based mapping applications. It works with vector and raster data from a variety of sources and is able to reproject data for rendering. The library has broad support for OGC protocols and formats, including WMS, WMTS, WFS, WKT, WKB, GML, and KML. In addition, it has support for community and non-OGC standards such as GeoJSON, XYZ tiles, TileJSON, GeoTIFF/COG, and more. OpenLayers is written in JavaScript and is available under the BSD 2-Clause license.

The ol/source/OGCMapTile module provides a source for map tiles from an OGC API – Tiles service. The ol/source/OGCVectorTile module provides a source for vector tiles from an OGC API — Tiles service.

4.2.8.  xyz2ogc

The xyz2ogc program supports the generation of OGC API – Tiles metadata from existing XYZ tilesets. The program is implemented in the Go programming language and the published module can be used in Go-based services that implement the OGC API – Tiles specification.

4.3.  Proprietary products

This section describes proprietary software products that were deployed during the code sprint.

4.3.1.  MariaDB CubeWerx CubeServ

The CubeWerx server (“cubeserv”) is implemented in C and currently implements the following OGC Standards and draft specifications.

  • Multiple conformance classes and recommendations of the OGC API — Tiles — Part 1: Core Standard.

  • Multiple conformance classes and recommendations of the OGC API — Maps — Part 1: Core candidate Standard.

  • All conformance classes and recommendations of the OGC API — Features — Part 1: Core Standard.

  • Multiple conformance classes and recommendations of the OGC API — Records — Part 1: Core candidate Standard.

  • Multiple conformance classes and recommendations of the OGC API — Coverages — Part 1: Core candidate Standard.

  • Multiple conformance classes and recommendations of the OGC API — Processes — Part 1: Core Standard.

  • Multiple versions of the Web Map Service (WMS), Web Processing Service (WPS), Web Map Tile Service (WMTS) and Web Feature Service (WFS) Standards.

  • A number of other “un-adopted” OGC Web Service draft specifications including the Testbed-12 Web Integration Service, OWS-7 Engineering Report — GeoSynchronization Service, and the Web Object Service prototype.

The cubeserv executable supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats (e.g., GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems.

4.3.2.  Ordnance Survey Implementation of OGC API — Styles

Ordnance Survey (OS) works with a wide array of customers and partners across many industries in the United Kingdom and beyond. A key part of the current OS Roadmap is the suite of products to deliver the OS National Geographic Database (OS NGD). At the end of September 2022, OS launched the OS NGD API – Features product which implements Parts 1, 2, and 3 of OGC API — Features to provide access to data along with filtering capabilities to enable customers to retrieve just the data they need. During the code sprint, developers from OS focuses on implementation of the OGC API — Styles candidate standard. The work at the code sprint complemented other OS activities that are implementing OGC API — Tiles.

4.3.3.  GNOSIS Map Server

The GNOSIS Map Server is written in the eC programming language and supports multiple OGC API specifications. GNOSIS Map Server supports multiple encodings including GNOSIS Map Tiles (which can contain either vector data, gridded coverages, imagery, point clouds or 3D meshes), Mapbox Vector Tiles, GeoJSON, GeoECON, GML and MapML. An experimental server is available online at https://maps.ecere.com/ogcapi and has been used in multiple OGC Innovation Program initiatives.

4.3.4.  Hexagon Luciad RIA

LuciadRIA is a product that enables applications running in a web browser to offer 2D, 3D, or 4D visualization of satellite and other imagery, vector-based data and dynamic content, such as tracks. LuciadRIA can connect to implementations of OGC API Standards, as well as implementations of OGC Web Service standards.

5.  Results

The code sprint included multiple software products and implementations of OGC and ISO Standards. This section presents some of the results from the code sprint.

5.1.  MariaDB CubeWerx CubeSERV

Developers from MariaDB configured an instance of their CubeSERV product to offer an OGC API — Maps interface in front of a WMS that was serving EuroGeographics’s EuroRegionalMap. A screenshot of the CubeSERV user interface is shown in Figure 2. The user interface lists the coordinate reference systems that are supported by the collection that is being retrieved.

Figure 2 — Screenshot of CubeSERV describing a collection

The styles that are supported by the collection can also be accessed, as demonstrated in Figure 3.

Figure 3 — Screenshot of CubeSERV describing styles supported by the collection

The supported map tiles can also be retrieved. A screenshot describing part of a supported tile matrix set is shown in Figure 4.

Figure 4 — Screenshot of CubeSERV describing a supported tile matrix set

5.2.  GNOSIS Map Server

A demonstration instance of GNOSIS Map Server was used in the code sprint to support implementation of various client applications, including for example Leaflet which is described in Clause 5.3. GNOSIS Map Server was also used to support the implementation of the Executable Test Suite, which is described in Clause 5.11.

Figure 5 shows a screenshot of the GNOSIS web client (left hand-side) and the responses it is receiving from an instance of GNOSIS Map Server (right hand-side). The interface between the client and server implements the OGC API — Tiles Standard. Notice that the responses are individual tiles encoded in the Mapbox Vector Tiles format.

Figure 5 — Screenshot of the GNOSIS web client (left) and responses from an instance of GNOSIS Map Server (right)

5.3.  Leaflet

5.3.1.  OGC API — Tiles implementation

Leaflet has built-in support for map tiles (or “TileLayer”s), but its internal implementation has significant constrains: All TileLayers must share the same coordinate system, must be aligned to the same origin of coordinates, and all tiles in any given TileLayer must have the same pixel size.

The flexibility of OGC API — Tiles in regards of tile size and origin of coordinates both prove a handicap for a Leaflet client implementation.

The reached consensus is to ignore TileMatrixSets which do not have a constant tile size, or that do not have a common origin of coordinates for the (0,0) tiles.

5.3.2.  OGC API — Maps implementation

An instance of leaflet was configured to access an OGC API — Maps implementation from a MariaDB CubeSERV instance. The CubeSERV instance had been configured to offer an OGC API — Maps façade in front of a WMS that offered layers of the EuroRegionalMap of EuroGeographics. A screenshot of the leaflet instance is shown in Figure 6.

Figure 6 — Screenshot of leaflet accessing implementations of OGC API - Maps and OGC API - Tiles.

5.4.  ldproxy

Sprint participants from interactive instruments GmbH updated ldproxy’s implementation of OGC API — Tiles and OGC API — Styles.

5.4.1.  OGC API — Tiles

The participants from interactive instruments GmbH updated their OS Zoomstack demonstration server to support the released version of OGC API — Tiles — Part 1: Core standard. Specifically, ldproxy now offers a link that can be followed to get to a tile matrix set definition. The link is provided through a uri property as shown in the following listing.

{
  "links" : [ {
    "rel" : "self",
    "type" : "application/json",
    "title" : "This document",
    "href" : "https://demo.ldproxy.net/zoomstack/tileMatrixSets?f=json"
  }, {
    "rel" : "alternate",
    "type" : "text/html",
    "title" : "This document as HTML",
    "href" : "https://demo.ldproxy.net/zoomstack/tileMatrixSets?f=html"
  } ],
  "tileMatrixSets" : [ {
    "title" : "Google Maps Compatible for the World",
    "links" : [ {
      "rel" : "self",
      "title" : "Tile matrix set 'WebMercatorQuad'",
      "href" : "https://demo.ldproxy.net/zoomstack/tileMatrixSets/WebMercatorQuad"
    } ],
    "id" : "WebMercatorQuad",
    "uri" : "http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad"
  } ]
}

Screenshots of the ldproxy landing page (a) and its WebMercatorQuad tile matrix set definition (b) are shown in Figure 7.

Figure 7 — Screenshot of the ldproxy landing page (a) and its WebMercatorQuad tile matrix set definition (b)

5.4.2.  OGC API — Styles

The ldproxy demonstration implementation of OGC API — Styles was updated with additional styles during the code sprint. The demo server provided a reference for other participants to validate their implementations by. A screenshot a listing of styles offered by the ldproxy demo is shown in Figure 8 (a) and metadata about a single style is demonstrated in Figure 8 (b).

Figure 8 — Screenshot of the listing of styles offered by the ldproxy demo (a) and style metadata (b)

The work on OGC API — Styles during the code sprint led to a pull request being created to update the candidate standard. The pull request clarifies how to apply changes to a style with multiple occurrences in an API.

5.5.  Hexagon Luciad RIA

TBA

5.6.  Miramon Map Browser

Sprint participants from CREAF extended the Miramon Map Browser to support the tiling of content from an implementation of the OGC SensorThings API. They also extended the Miramon Map Browser to support the addition of layers from implementations of OGC API — Maps.

Figure 9 — Screenshot of the Miramon Map Browser configuration for layers from OGC API — Maps

Figure 10 shows a screenshot of the Miramon Map Browser accessing a SensorThings API (top) and with objects being queried (bottom). The use case implemented was that of aggregation of objects in tiles, and the presentation of the number of objects in each tile. This addressed the situation of a server that offers a significant number of vector objects, whether those objects represent features, sensors, or their observations. Miramon was configured to issue a request for each tile twice, the first request is for getting the count (i.e. number of objects in a tile), and then second request is for getting the actual objects.

Figure 10 — Screenshot of the Miramon Map Browser accessing a SensorThings API (top) and with objects being queried (bottom)

5.7.  Ordnance Survey Implementation of OGC API — Styles

Sprint participants from Ordnance Survey implemented a prototype that supports OGC API — Styles. The prototype was implemented to offer the landing page, API definition, conformance declaration, list of styles, and styles metadata. To demonstrate the prototype, Esri stylesheets were served through the API. The prototype was implemented to support both the British National Grid projection (which has the identifier EPSG:27700) and the WGS 84 / Pseudo-Mercator (which has the identifier EPSG:3857).

Figure 11 — Screenshot of the landing page of the OS NGD Styles API prototype

In addition to supporting the publication of styles, the prototype was implemented to also support the management of styles. The functionality was demonstrated during the code sprint, using Postman to send the request for creating a style. Future work will involve implementation of input validation, handling of error responses, support for PATCH functionality, and support for the management of resources such as sprites and fonts.

Figure 12 — Screenshot of the styles list of the OS NGD Styles API prototype

5.8.  OGC Styles and Symbology

A breakout session on OGC Styles and Symbology discussed potential Conformance Classes for a new OGC Styles and Symbology Standard.

The sprint participants went through the conformance classes to check that none were missing, and found that some were indeed missing. An example of a conformance class that was missing is the Geometry Selection conformance class in relation to the possibility of a symbolizer accessing the underlying geometry to manipulate it. Such a capability could be applied to visualisation of proportional symbols, for example, transforming a polygon into a point with ST-Centroid to draw a proportional symbol.

As several OGC Styles and Symbology SWG members participated in the breakout session, the discussions will help to move towards a version 2.0 “Styles & Symbology Model & Encodings” that includes SymCore and the conceptual/logical definitions of the concrete extensions to be packaged in a Part 1. The sprint participants started the documentation of the envisaged version 2.0 on GitHub. It terms of naming, the SWG members plan to keep the SymCore name for version 2.0.

In parallel, the sprint participants worked on relevant use cases to test the functional coverage of the proposed model and to relate them to the conformance classes. The use cases are presented in Annex A. In doing so, the sprint participants tested existing encodings (e.g. GeoCSS) to start imagining the “natural” encoding that could also be documented with Part 1 of the “Styles & Symbology Model & Encodings” candidate standard. The use cases will continue to inspire and inform the work of the SWG for the next few months as the next major milestone will be the 125th OGC Member Meeting, to be held February 2023.

5.9.  OWSLib

The OWSLib project implemented client capability for the OGC API — Records — Part 1: Core draft specification. Support for the “Requirements Class “Map Core” was implemented, reviewed and approved by the OWSLib development team. As a result, Python clients can now use OWSLib for simple Pythonic workflows to request and visualize data from an OGC API — Maps service.

A screenshot of a sample Python/OWSLib workflow of the new functionality is shown in the figure below.

Figure 13 — Screenshot of a sample Python/OWSLib workflow

A screenshot of the OWSLib OGC API — Maps demo is shown below.

Figure 14 — Screenshot of the OWSLib OGC API — Maps demo

5.10.  pygeoapi

5.10.1.  OGC API — Maps implementation

The pygeoapi project implemented support for the OGC API — Maps — Part 1: Core draft specification. Support for the Requirements Class “Map Core” was implemented, reviewed and approved by the pygeoapi development team. As a result, pygeoapi implementations are now able to easily publish geospatial data as dynamic maps thanks to the building block approach of OGC API Standards.

pygeoapi’s plugin architecture facilitated the implementation of two plugin backends for maps:

  • MapScript: using the MapServer[https://mapserver.org] web mapping engine as the map renderer, using data and styling definitions (Styled Layer Descriptor [SLD], MapServer CLASS configuraiton files).

  • WMSFacade: a bridge/mediator to expose existing OGC WMS 1.3 services via OGC API — Maps

The official pygeoapi documentation provides more information on how to enable the new functionality. A screenshot of the associated OpenAPI/Swagger interface from the implementation is shown in the figure below.

Figure 15 — Screenshot of pygeoapi OGC API — Maps MapScript plugin

Figure 16 — Screenshot of pygeoapi OGC API — Maps WMSFacade plugin

Figure 17 — Screenshot of pygeoapi OGC API — Maps via OpenAPI/Swagger

Figure 18 — Screenshot of pygeoapi OGC API — Maps WMSFacade using the Open Maps for Europe WMS from Eurogeographics

5.10.2.  OGC API — Tiles updates

5.10.2.1.  Tile Metadata

Support for the Tile Set Metadata schema has been added to TileJSON MapBox. It is also possible to support any format by adding a JSON metadata file directly into the filesystem. As well, the absence of metadata does not represent an issue, facilitating support for different tiles providers.

Figure 19

5.10.2.2.  Vector tiles URL templates

pygeoapi added support for rendering OGC API — (vector) tiles from a third-party service, using a generic URL template. One use case for this functionality would be to stream elasticsearch vector tiles, which are provided in elasticsearch >=8, as OGC API — Tiles.

Figure 20 — Screenshot of pygeoapi OGC API — Tiles using the Elasticsearch vector tiles

We could also use this functionality to render pg_tileserv vector tiles, or any other service which uses format {z}/{y}/{x} or {z}/{x}/{y}

Figure 21 — Screenshot of pygeoapi OGC API — Tiles connecting to a pg_tileserv vector tiles service

5.10.3.  OGC API — Coverages browser rendering

pygeoapi gained HTML representation of a coverages, as a lightweight HTML viewer.

This viewer is a Leaflet[https://leafletjs.com/] implementation, which uses the Leaflet.ImageOverlay.Arrugator[https://gitlab.com/IvanSanchez/Leaflet.ImageOverlay.Arrugator/] plugin, and the proj4js[https://github.com/proj4js/proj4js/] library to provide client-side reprojection. Whenever a web browser visits a /coverage path on pygeoapi, the web browser sends an Accept: text/html header which triggers pygeoapi to respond with the lightweight coverage viewer.

Figure 22 — Screenshot of pygeoapi lightweight coverage viewer

The emphasis is not in the viewer, but rather in the fact that the viewer is the HTML representation of the coverage resource. Whenever a API client requests the coverage resource, it will be given a HTML map viewer, or the JSON-LD representation of the coverage, or the raw coverage data (as PNG, GeoTIFF, NetCDF, etc), in accordance to the established HTTP content negotiation rules (“Accept” HTTP headers, or “f” URL parameter).

This is aligned with pygeoapi’s implementation of OGC API — Features, where requesting features as HTML returns a map viewer loaded with those features.

5.10.4.  Mentor session

A pygeoapi mentor session was provided in support of delivering Vector Tiles using pygeoapi. The session focused on:

  • installation

  • overview of various endpoints and Creating standard source

  • creating vector tiles

  • serving vector tiles

  • reading vector tiles from different clients

5.10.5.  Developer outreach

Members of the pygeoapi development team discussed project participation and contributions with various developers at the sprint.

5.11.  TEAM Engine

The focus of work was put on the OGC CITE executable test suite (ETS) OGC API — Tiles.

The code sprint was structured by creating GitHub issues for tasks to be worked on. In total, five issues were part of the code sprint. Following screenshot summarizes those issues.

Figure 23 — Screenshot of GitHub issues created during code sprint

A focus was put on cleaning up the test suite and re-structuring it so that it is closer to the structure of the abstract test suite of the standard. Afterwards, the test implementation of the Core conformance class was enhanced. This includes the parsing of the OpenAPI document which is required to extract parameters needed to build requests. The parsing of the OpenAPI document is also part of the Tilesets List conformance class. In addition, an already reported bug was solved.

The result can be summarized by a screenshot of the HTML report of OGC API — Tiles test suite created by TEAM Engine. The report structures the already existing tests into the correct conformance classes and gives an overview of already implemented tests.

Figure 24 — Screenshot of HTML report of OGC API — Tiles test suite created by TEAM Engine

5.12.  OpenLayers

5.12.1.  OGC API – Tiles updates

A previous OpenLayers release had “experimental” support for rendering tiles from OGC API – Tiles services. This was added prior to the OGC API – Tiles standard being finalized.

During the sprint, the implementation was tested against services conforming to the Tileset conformance class. Changes were proposed to graduate the the source classes for rendering vector and map tiles from experimental to stable. These changes were approved, and the classes will be part of the OpenLayers API in the next release.

Figure 25 — Map tiles from an OGC API – Tiles service in OpenLayers

Figure 26 — Vector tiles from an OGC API – Tiles service in OpenLayers

5.13.  xyz2ogc

The xyz2ogc program was developed to demonstrate how metadata can be added to XYZ tilesets to conform with additional OGC API – Tile conformance classes. A goal of the project was to investigate how much of the OGC API – Tile specification can be implemented as a “static” service.

The xyz2ogc program has two primary commands: serve and generate. The program is configured with a single TOML file that lists URL templates and additional optional metadata for existing XYZ tilesets. The serve command reads the configuration file and starts a local webserver that provides OGC API – Tile compliant metadata. The generate command writes out a set of metadata files that can be hosted as a static website conforming to the specification.

The program generates metadata that conforms to the following OGC API – Tile conformance classes:

5.13.1.  Findings

The OGC API – Tiles specification makes it easy for existing XYZ tilesets to conform with the Core requirements. This is possible as long as the service provides some way for the tile URL template and the meaning of the variables in that template to be obtained.

Since many existing XYZ tilesets do not have a formalized way for clients to obtain the tile URL template or understand the meaning of the variables, it makes sense for tile providers to “upgrade” their services by conforming with the Tileset requirements.

In practice, conforming with the Tileset requirements means hosting two metadata documents for a single XYZ tileset: one providing the tileset metadata and one describing the tiling scheme. This can be reduced to a single document for the tileset metadata linking to an existing document hosted elsewhere that describes the tiling scheme.

It would be more convenient if OGC specifications were developed in a way that URIs for things like CRS or TileMatrixSet resolved to definitions of those resources. For example, it would be convenient if the WebMercatorQuad URI resolved to the definition for this tile matrix set. This would allow the tiling scheme for a tileset to be specified with the tile matrix set URI alone, and clients could reliably fetch the definition from this. Unfortunately, it is not enough for the OGC URIs to redirect to a different resource providing this content. A browser-based client served via the HTTPS protocol will not fetch the OGC URI unless it is served via HTTPS (to avoid mixed active content violations) and it is served with Cross-Origin Resource Sharing (CORS) headers.

Suggestion: If in the future OGC URI 1) used the HTTPS scheme, 2) resolved to useful resources, and 3) were served with CORS headers, it would make browser-based client implementations easier.

For services providing more than a single tileset, it makes sense to conform to the Tileset List requirements. Having conformed with the Tileset requirements, it is mostly straightforward to conform to the Tileset List requirements by providing a document that lists the metadata (or a subset of the metadata) for each tileset. In the case of a static server, requirement 9 adds a small additional burden on implementators. The specification requires that the URL for the list of tilesets ends with /tiles. In many cases, static servers determine the conent type for a response based on a document extension. For example, a common pattern is to have an index.html document that the server will provide in response to a request that matches a directory location (e.g. https://example.com/path/to/directory/). The same can be done for an index.json document with a list of tilesets as long as the service can be configured to treat index.json files as the “default” document. The additional potential complication is that the service may need to be configured to redirect a slash-less URL (e.g. https://example.com/path/to/tiles) to a URL ending in a slash (e.g. https://example.com/path/to/tiles/) so that the default document will be served.

Suggestion: If there is not a real benefit to requiring that the tileset list URL ends with /tiles, perhaps a future version of the specification could relax or remove this requirement.

In addition to the Tilset, Tileset List, and associated TMS conformance classes, the xyz2ogc program implements a few of the conformance classes from OGC API – Common, namely Core, JSON, and OpenAPI 3.0. However, xyz2ogc chose not to implement the additional requirements from the OGC API – Tiles OpenAPI 3.0 conformance class. In particular, the requirements related to homogenous collections of tilesets (e.g. not including vector tiles in a list that includes map tiles) didn’t match the design of the project (a single listing of tilesets that may include both vector and map types). A client capable of rendering both vector and map tiles can make this distinction invisible to users, and the idea with the xyz2ogc program is to provide users with a list of tilesets to choose from – dividing those into multiple lists based on tile content type seems arbitrary and a bit awkward.

Suggestion: In the future, it could be useful if the specification allowed for linking to tilesets lists of mixed types.

6.  Discussion

6.1.  JPEG or PNG responses

JPEG images are typically an order of magnitude smaller in byte size than PNG images of a similar width and height in pixels. JPEG images therefore result in a much more responsive experience, but they do not support transparency, so layer overlays are impossible. PNG images, on the other hand, do support transparency, but are typically larger in byte size for a similar width and height in pixels. Some client implementations deal with this by requesting the bottom layer as JPEG and all overlay layers as PNG, but this is far from ideal. One somewhat common solution is to support a “JPEG or PNG” format (represented by a requested content type of “image/x-jpegorpng” or “image/jpgpng” or a format string of “jop”). When this format is requested, the server can return the requested image in the optimal image format (typically PNG if there’s transparency and JPEG otherwise). Several implementations, including CubeSERV, have taken this approach, and it has proven to be a highly effective optimization. However, the WMS and WMTS specifications failed to standardize such a request format, so this optimization isn’t interoperable.

This is not an issue for the “OGC API — Maps” and “OGC API — Tiles” Standards, since they support format (i.e., content type) negotiation through use of the HTTP Accept request header. A client can simply indicate Accept: image/png, image/jpeg, which literally means “give me whichever of these two formats you consider the most appropriate”. And as a bonus, a typical web browser will send an Accept string which gives image/jpeg and image/png equal weighting, so JPEG-or-PNG negotiation can automatically occur even through simple web-browser requests. It should be noted that some modern web browsers send an Accept: image/avif, image/webp, /` header, which suggests that they prefer some of the newer formats which also happen to support an alpha channel. Therefore, use of the Accept header as already implemented by OGC API Standards also enables support for other encoding options.

However, there is a concern that most implementers of the “OGC API — Maps” and “OGC API — Tiles” Standards might not recognize the importance of this logic, and would likely write code which just chooses the first supported format in the list. There is therefore a need for awareness of this mechanism because such a mechanism is important enough to be explicitly provided as a recommendation in both the “OGC API — Maps — Part 1: Core” and “OGC API — Tiles — Part 1: Core” Standards.

A Recommendation could be added to an OGC API — Maps User Guide or some other developer resource. The sprint participants suggested that the SWG considers the following text for addition to a User Guide:

  • If both “image/png” and “image/jpeg” are supported at an endpoint and are present in the HTTP “Accept” request header with the same q value, and no other supported output format is present with a higher q value, the server should return the requested image in whichever of these two formats is considered optimal (typically PNG if there’s transparency and JPEG otherwise).

Regarding the “f” parameter, if servers implement an “f” parameter that overrides the HTTP “Accept” request header, the servers would have the option of supporting custom values such as “jop” or “image/x-jpegorpng” which would trigger the optimization. However, since “jop” or “image/x-jpegorpng” are not standardized parameter values for indicating an encoding, the Standards need not provide any recommendations to this effect.

6.2.  Data Statistics

Many clients have the need to retrieve a feature count element from the server, in order to construct their visualizations. OGC API — Features addresses this need through a property called “numberMatched” when a feature collection is retrieved. However, this leads clients sometimes to issue two separate get items requests: one to count the items, and another one to actually draw them.

There’s a parallel with OGC API — Coverages: one of the use cases is fetching the coverage metadata (width, height, dimensions (2-3), bit depth, time dimension, number of channels/bands, native CRS) but not the data itself. That’s how the pygeoapi viewer implementation works as of now.

OGC API — Tiles addresses this issue by offering tile set metadata and TileMatrixSet definitions. However, a similar ability to retrieve data statistics without retrieving the data appears to be missing from OGC API — Features and OGC API — Coverages.

The sprint participants suggested that a super class for presenting data statistics could be specified in OGC API — Common and then specialised in other OGC API Standards.

6.3.  Cancel Requests

When requesting tiles, and panning around, clients often leave behind requests from tiles which are no longer in the viewport. This has a performance cost, as the server gets overloaded with requests which are no longer needed. One way of handling this situation, would be to fire a cancel request, for tiles which are no longer in the viewport. Some popular browsers, such as Mozilla Firefox, support this capability through the XMLHttpRequest.abort() method.

The sprint participants suggested the following as recommendations:

  • Clients should be able to send a cancel or abort request so that a server aborts a long-running operation.

  • Clients for OGC API — Maps should make a best effort to avoid making several requests in shorts periods of time (e.g. 1 second)

  • Servers for OGC API — Maps can reply with HTTP code 429 Too Many Requests if a client is straining the server resources

6.4.  Security/access control

The EuroGeographics WMS access token as applied in OGC API — Maps via pygeoapi brought forth questions about how cascading / broker services deal with secure services. The pygeoapi documentation provides an overview on security and access control. The September 2020 OGC API Code Sprint included a security thread OGC 20-091, however since then there has not been a similar thread in OGC Code Sprints. There was a suggestion to have a sprint (or thread in same) focused on general security/access control issues, across OGC API and broader OGC standards. There are several implementations of OGC API Standards that implement access control mechanisms. Such a code sprint could pull in lessons learnt from many of the OGC API implementations that support access control, for example Ordnance Survey’s NGD API — Features, NLS Finland’s Topographic Database, and those from the OGC Testbeds OGC 21-020r1.

6.5.  Filtering of styles

There was a discussion about whether it is possible to filter styles returned by an implementation of OGC API — Styles, in a standardised way. Currently, just like with OGC API — Features, a client simply receives a list of collections without the ability to filter the collections according to a specific criteria. There have been suggestions that all collections should have the ability to be filtered. This would support the ability to filter on a particular field, such as the description. A client would only get the list of styles that are relevant to that filter. Whereas it is possible to do, at present this capability is not standardised.

6.6.  HTML Previews

There was a discussion about the retrieval of HTML previews of data from an OGC API implementation. This followed the work described in Clause 5.10.3 regarding a coverage viewer for pygeoapi. It was noted that the ability to request an HTML representation of a dataset means that an OGC API could potentially also offer support for querying a dataset through a web browser. This leaves the question of how a query language such as CQL2 could be applied to tile matrix sets. Further, the HTML Preview capability creates an opportunity to enable the actual data to be queried such that the value of a location on a coverage can be retrieved rather than the RGB (Red-Green-Blue) values of the image that is presented. The sprint participants noted that this could be a topic for a testbed or another type of innovation initiative.

Another topic discussed in relation to HTML Previews was that the Accept header or “f” parameter indicated the format of the response payload, but not the format of any embedded elements. So there is an expectation that the web browser supports whichever image format is embedded in the HTML response of the API. One option is to introduce a recommendation that if one of the media types is text/html, and the other is an image, then the server should return an HTML Preview that contains an image in the format specified. The sprint participants also noted that HTML offers a <picture> element which contains an <img> element, as well as zero or more <source> elements that offer alternative versions of an image for different situations HTML. A web browser considers each <source> element and selects the most appropriate among them. If there are no appropriate options, the web browser uses the URL in the src attribute of the <img> element is selected.

6.7.  Creating and Updating Styles

There are two issues regarding the HTTP PUT method and how it might be applied to OGC API — Styles. The first issue is related to the fact that there can be different style sheets for a single style. An API can offer a resource in multiple encodings, for example SLD, ArcGIS, MapInfo, Mapbox or others. This leads to the questions of: Should changes to a resource be propagated to each of the encodings? What happens in situations where the encodings do not support a concept that is supported by other encodings? A pull request was created that addresses aspects of this challenge. The pull request will be discussed by the SWG after the code sprint.

The second issue is regarding specification of the PUT mechanism in the OGC API — Styles candidate standard itself. OGC API — Features — Part 4 was the first of the OGC API candidate standards to specify interfaces for create, replace, update, and delete operations. OGC API — Features — Part 4 has two different Requirements Classes, one is general and is written for any resource. The other requirements class is for features. OGC API — Styles implements the general resource requirements class — which could be eventually moved to OGC API — Common. The idea is for the general resource requirements class to support the ability to create a style when it receives a PUT request with an identifier.

7.  Conclusions

TBA

7.1.  Future Work

The sprint participants made the following recommendations for future innovation work items:

  • Prototyping and demonstration of support for the querying of coverages in HTML Previews of coverage tiles

  • TBA

  • TBA

The sprint participants also made the following recommendations for things that the SWGs should consider:

  • A code sprint focused on general security/access control issues, across OGC API and broader OGC standards

  • The OGC API — Styles SWG needs to be reinvigorated in order to push the candidate standard to completion

  • TBA

It is envisaged that the SWGs will consider the above-listed recommendations for future work items.


Annex A
(informative)
Styles and Symbology Use Cases

This annex presents the Styles and Symbology use cases that were discussed and documented during the code sprint.

A.1.  Graduated and Categorized: conditional coloring of a map

This use case is discussed in styles-and-symbology#Issue 17.

Existing conformance classes required for this use case:

  • Symbology Core: Class Symbolizer

  • Example stylesheet:

Describe any capability not already addressed by existing conformance classes:

  • Categorized: coloring map according to a unique value eg. coloring map according to region name (unique value)

  • Graduated: coloring map according to a range of values eg. coloring map according to the population of a zone in a particular range(0-5000, 5000-10000)

Example image illustrating the portrayal use case:

  • Categorized:

Figure A.1 — Categorized conditional coloring of a map

  • Graduated

Figure A.2 — Graduated conditional coloring of a map

One possible solution is that when classes are unknown (in a raster map) then pixel gradient values can be used to group the pixels into classes and to color them according to that class, creating a choropleth or graduated map. In this use case, the vector data is presented as graduated (colour maps) even where there is a large number of unknown classes.

A.2.  Unique values map

This use case is discussed in styles-and-symbology#Issue 18.

Existing conformance classes required for this use case:

  • basic vector feature styling

Example stylesheet:

Below a CSS encoding to describe a unique values map to display Local Climate Zones type (LCZ_PRIMARY property).

/* Metadata
* @title Local Climate Zones I
* @abstract Local Climate Zones I
*/

/* Main rule*/

* {
  stroke: rgb(255,255,255);
  stroke-width: 0.26;

/* Styling according to the Local Climate Zones */

  /* @title LCZ 1: Compact high-rise */
  [LCZ_PRIMARY = 1] {
    fill: rgb(139, 1, 1);
  };
  /* @title LCZ 2: Compact mid-rise */
  [LCZ_PRIMARY = 2] {
    fill: rgb(204, 2, 0);
  };
  /* @title LCZ 3: Compact low-rise */
  [LCZ_PRIMARY = 3] {
    fill: rgb(252, 0, 1);
  };
  /* @title LCZ 4: Open high-rise */
  [LCZ_PRIMARY = 4] {
    fill: rgb(190, 76, 3);
  };
  /* @title LCZ 5: Open mid-rise */
  [LCZ_PRIMARY = 5] {
    fill: rgb(255, 102, 2);
  };
  /* @title LCZ 6: Open low-rise */
  [LCZ_PRIMARY = 6] {
    fill: rgb(255, 152, 86);
  };
  /* @title LCZ 7: Lightweight low-rise */
  [LCZ_PRIMARY = 7] {
    fill: rgb(251, 237, 8);
  };
  /* @title LCZ 8: Large low-rise */
  [LCZ_PRIMARY = 8] {
    fill: #bcbcba;
  };
  /* @title LCZ 9: Sparsely built */
  [LCZ_PRIMARY = 9] {
    fill: rgb(188, 188, 186);
  };
  /* @title LCZ 10: Heavy industry */
  [LCZ_PRIMARY = 10] {
    fill: rgb(87, 85, 90);
  };
  /* @title LCZ A: Dense trees */
  [LCZ_PRIMARY = 101] {
    fill: rgb(0, 103, 0);
  };
  /* @title LCZ B: Scattered trees */
  [LCZ_PRIMARY = 102] {
    fill: rgb(5, 170, 5);
  };
  /* @title LCZ C: Bush,scrub */
  [LCZ_PRIMARY = 103] {
    fill: rgb(100, 132, 35) ;
  };
  /* @title LCZ D: Low plants */
  [LCZ_PRIMARY = 104] {
    fill: rgb(187, 219, 122);
  };
  /* @title LCZ E: Bare rock or paved */
  [LCZ_PRIMARY = 105] {
    fill: rgb(1, 1, 1);
  };
  /* @title LCZ F: Bare soil or sand */
  [LCZ_PRIMARY = 106] {
    fill: rgb(253, 246, 174);
  };
  /* @title LCZ G: Water */
  [LCZ_PRIMARY = 107] {
    fill: rgb(109, 103, 253);
  };
}

Figure A.3

Describe any capability not already addressed by existing conformance classes:

Example image illustrating the portrayal use case:

Figure A.4 — Unique values map

Material: Data : https://github.com/orbisgis/POC-Carto/blob/main/data/rsu_lcz.geojson

Tool : https://github.com/orbisgis/POC-Carto Based on Geotools library

A.3.  Choropleth or graduated map

This use case is discussed in styles-and-symbology#Issue 19.

Existing conformance classes required for this use case:

  • basic vector feature styling

Example stylesheet:

Below a CSS encoding to describe a graduated map to display fraction of vegetation on a grid (HIGH_VEGETATION_FRACTION property).

*{
  stroke: #000000;
  stroke-width: 1px;
  [HIGH_VEGETATION_FRACTION>=0 OR HIGH_VEGETATION_FRACTION<=0.200]
  {
     fill: yellow;
  };
  [HIGH_VEGETATION_FRACTION>0.200 OR HIGH_VEGETATION_FRACTION<0.500]
  {
     fill: orange;
  };
  [HIGH_VEGETATION_FRACTION>0.500]
  {
     fill: red;
  };
}

Figure A.5

Describe any capability not already addressed by existing conformance classes:

Example image illustrating the portrayal use case:

Figure A.6 — Choropleth or graduated map

A.4.  Proportional symbol

This use case is discussed in styles-and-symbology#Issue 20.

Existing conformance classes required for this use case:

  • vector feature styling

  • viz/feature.pass (define conformance classes) 🧨

  • geometry selection 🧨

  • Geometry Manipulation Functions (centroid 🧨)

  • Interpolate function 🧨

  • Shape Graphics

Example stylesheet:

Below a CSS encoding to describe a proportional symbol map to display number of inhabitants on a regular grid (SUM_POP property).

*{
  stroke: grey;
  stroke-width: 1px;
  [SUM_POP>0] {
    geometry: centroid(the_geom);
    mark:   symbol(circle);
    mark-size: [Interpolate(
         SUM_POP,
         0, 10,
         30, 20,
         84, 100,
         'numeric',
         'linear')];
   :mark {
       fill: orange;
       fill-opacity: 0.2;
       stroke: black;
       stroke-width : 1px;
     }
  }
}

Figure A.7

Describe any capability not already addressed by existing conformance classes:

Example image illustrating the portrayal use case:

Figure A.8 — Proportional symbol

A.5.  Proportional bivariate map

This use case is discussed in styles-and-symbology#Issue 21.

Existing conformance classes required for this use case:

Not specified.

Example stylesheet:

Below a CSS encoding to describe a proportional symbol map with a color for each Local Climate Zones type filtered to represent a climate aleas.

*{
 [LCZ_PRIMARY != 104]{
   stroke: grey;
   stroke-width: 1px;
 }
 [SUM_POP>0] {
    geometry: centroid(the_geom);
    mark:   symbol(circle);
    mark-size: [Interpolate(
         SUM_POP,
         0, 10,
         30, 20,
         84, 100,
         'numeric',
         'linear')];
 };
 /* @title high climate risk */
 [LCZ_PRIMARY = 1],
 [LCZ_PRIMARY = 2],
 [LCZ_PRIMARY = 3],
 [LCZ_PRIMARY = 10],
 [LCZ_PRIMARY = 105]{
   :mark{
     fill: red;
   }
 };

 /* @title moderate climate risk */
 [LCZ_PRIMARY = 4],
 [LCZ_PRIMARY = 5],
 [LCZ_PRIMARY = 6],
 [LCZ_PRIMARY = 7],
 [LCZ_PRIMARY = 8],
 [LCZ_PRIMARY = 9]{
   :mark{
     fill: orange;
   }
 };

 /* @title low climate risk */
 [LCZ_PRIMARY = 101],
 [LCZ_PRIMARY = 102],
 [LCZ_PRIMARY = 103],
 [LCZ_PRIMARY = 106],
 [LCZ_PRIMARY = 107]{
   :mark{
     fill: green;
   }
 };
 }

Figure A.9

Describe any capability not already addressed by existing conformance classes:

Example image illustrating the portrayal use case:

Figure A.10 — Proportional bivariate map

A.6.  Dot map density

This use case is discussed in styles-and-symbology#Issue 22.

Existing conformance classes required for this use case:

  • Dashes, Stipples, Hatches and Gradients

  • (conformance class for more specific stippling)

Example stylesheet:

Bellow a CSS encoding to describe a dot map. A do map is used to create a visual impression of density by placing a dot or some other symbol in the approximate location of one or more instances of the variable being mapped. The mapped variable is the area of the LCZ geometry. The dot map can be colored according the LCZ types. a.e : LCZ equals to 1, 2 , 3 filled in red to represent a high climate aleas.

Describe any capability not already addressed by existing conformance classes:

DotFill must be defined with the following properties

  • quantityPerMark : the quantity represented by a single dot.

  • totalQuantity : the total quantity to be represented.

  • mode : the algorithm to distribute the mark random, grid…​ a mark or a set of marks

Example image illustrating the portrayal use case:

Figure A.11 — Dot map density

A.7.  Bivariate proportional symbol

This use case is discussed in styles-and-symbology#Issue 23.

Existing conformance classes required for this use case:

Example stylesheet:

Bivariate map is a technique in cartography to display two different thematic variables at the same time. One of the most commun technique to create a bivariate map is to combine of visual variables. For most cartographers it may better support different map reading tasks. The following map uses the same visual variable to represent two variables (Half Circle). It permits a cross-variable comparison between the number of permits in 2005 and 2014.

*{
  stroke: grey;
  stroke-width: 1px;
  [NB_PERMITS_2005>0] {
    geometry: centroid(the_geom);
    mark:   symbol(semicircle);
    mark-size: [Interpolate(
         NB_PERMITS_2005,
         0, 10,
         659, 100,
         'numeric',
         'linear')];
   :mark {
       fill: rgb(153, 153, 255);
       fill-opacity: 0.2;
       stroke: black;
       stroke-width : 1px;
     }
  };
    [NB_PERMITS_2014>0] {
      geometry: centroid(the_geom);
      mark:   symbol(semicircle);
      mark-size: [Interpolate(
           NB_PERMITS_2014,
           0, 10,
           659, 100,
           'numeric',
           'linear')];
     :mark {
         fill: rgb(102, 0, 204);
         fill-opacity: 0.2;
         stroke: black;
         stroke-width : 1px;
         rotation: 180deg;
       }
    }
}

Figure A.12

Describe any capability not already addressed by existing conformance classes:

Example image illustrating the portrayal use case:

Figure A.13 — Bivariate proportional symbol

An additional example is presented below.

Figure A.14 — Additional example of Bivariate proportional symbol

A.8.  Custom fill

This use case is discussed in styles-and-symbology#Issue 24.

Existing conformance classes required for this use case:

Example stylesheet: The following map shows assembled visual variables expressed with custom fills : Graphic Fill and Hatched Fill.

Describe any capability not already addressed by existing conformance classes:

HatchedFill must be defined with the following properties

  • angle : the orientation of the hatches

  • distance : the perpendicular distance between two hatches

  • offset : the offset of the hatches.

  • stroke

Example image illustrating the portrayal use case:

Figure A.15 — Custom fill

An additional example of Custom fill is shown below.

Figure A.16 — Another example of Custom fill

A.9.  Proportional colored text

This use case is discussed in styles-and-symbology#Issue 25.

Existing conformance classes required for this use case:

Example stylesheet:

Proportional label map uses the same technique than proportional symbols, expected that the size of the font is scaled proportionately.

Here we describe a CSS file that represents the Local Climate Zone types with a text and a color according a climate aleas.

*{
     stroke: grey;
     stroke-width: 0.26;
     label: [LCZ_PRIMARY];
     font-family: Arial;
     font-size: [Interpolate(
                           area(geometry)/10000,
                           0, 10,
                           5, 20,
                           10, 32,
                           'numeric',
                           'linear')];
      font-style: normal;
      font-weight: bold;
      font-fill: black;
      label-anchor: 0.5 0.5;
      label-auto-wrap: 60;
      label-max-displacement: 150;

       /* @title high  */
          [LCZ_PRIMARY <= 4],
          [LCZ_PRIMARY = 8],
          [LCZ_PRIMARY = 10],
          [LCZ_PRIMARY = 105] {
              font-fill: red;
          };
          /* @title mid */
          [LCZ_PRIMARY >= 5]
          [LCZ_PRIMARY <= 7],
          [LCZ_PRIMARY = 9],
          [LCZ_PRIMARY = 10] {
           font-fill :orange;
          };
          /* @title low */
          [LCZ_PRIMARY >= 101]
          [LCZ_PRIMARY <= 104],
          [LCZ_PRIMARY = 107]{
            font-fill:  green;
          }
}

Figure A.17

Describe any capability not already addressed by existing conformance classes:

Example image illustrating the portrayal use case:

Figure A.18 — Proportional colored text


Annex B
(informative)
Revision History

Date Release Author Primary clauses modified Description
2016-04-28 0.1 G. Editor all initial version

Bibliography

[1]  Gobe Hobona: OGC 20-091, OGC API – Common and OGC API – Features Sprint 2020: Summary Engineering Report. Open Geospatial Consortium (2021). https://docs.ogc.org/per/20-091.html.

[2]  Andreas Matheus: OGC 21-068, OGC Best Practice for using SensorThings API with Citizen Science. Open Geospatial Consortium (2022). https://docs.ogc.org/bp/21-068.pdf.

[3]  Aleksandar Balaban, Andreas Matheus: OGC 21-020r1, OGC Testbed-17: Data Centric Security ER. Open Geospatial Consortium (2022). https://docs.ogc.org/per/21-020r1.html.